Combining video material and data

ABSTRACT

A method of combining data with other material comprises the step of repetitively distributing the data in the other material. The data is for example metadata associated with the other material. The other material may be one or more of video, audio and data material preferably in a defined file format e.g. MXF. The material and data from the file are preferably mapped to one of several signal interfaces such as SDI, SDTI and AES3, where the file metadata is repetitively distributed through the stream signal interface by one of several multiplexing methods.

[0001] The present invention relates to a method and apparatus forcombining data with other material. The present invention also relatesto a signal processing apparatus arranged to carry out the method, adigital bitstream and a computer program product.

[0002] ‘Material’ means any one or more of video, audio, and dataessence.

[0003] Embodiments of the invention relate to combining metadata withmaterial. Preferred embodiments of the invention relate to combiningmetadata with video and audio material and the invention and itsbackground will be discussed by way of example, and for greater clarity,with reference to such preferred embodiments but the invention is notlimited to that.

[0004] Metadata is information associated with material such as videoand audio. Some types of metadata describe the form of encoding of e.g.a compressed video signal to assist in the decoding thereof. Other typesof metadata describe the content of the video. For example suchdescriptive metadata may include the title of the video and otherinformation such as when and where the video was shot. Yet other typesof metadata are technical information such as aspect ratio, lens used,video format etc. Yet further types include information such as GoodShot Markers, copyright information, and information about peopleappearing in the video. Many other types of data may be metadata.

[0005] A prior proposal suggested that metadata is stored separatelyfrom the material with which it is associated. The metadata may bestored in a data base and some means of linking it with the material isprovided. Such means could be e.g. a code on a video-cassette. If thelink is lost then the metadata cannot be associated with the material.If the database is destroyed then the metadata is lost. Thus it isdesirable to combine at least some metadata with the material.

[0006] It is necessary to store material in a store such as a digitalvideo tape recorder (DVTR)or a digital disc recorder. It is alsodesirable to repeat metadata so that it can be accessed more easily ine.g. a tape record without needing to spool back to the beginning of thetape. However most DVTRs and disc recorders have a data format whichdoes not provide data space dedicated to metadata repeated at regularintervals in the digital bitstream.

[0007] According to one aspect of the present invention, there isprovided a method of combining digital data with other digital materialcomprising the steps of:

[0008] structuring the said digital data into a data structure having akey field, a length field and a value field, the value field containingthe data;

[0009] creating a digital bitstream having a predetermined repetitiveformat compatible with a data recorder each repetition of the formatincluding at least one data space for the said other material and a dataspace for other data; and

[0010] repetitively including the data structure over a plurality ofrepetitions of the format, the said data structure being included in thesaid other data space or in part of the data space of the said othermaterial.

[0011] By including the data structure in the said format, the datastructure can be accommodated in the format of the data recorder. Therepetition allows the data structure to be accessed without the need toreturn to e.g. the beginning of a tape if the recorder is a taperecorder.

[0012] A further step of the method optionally comprises the step ofmapping the combined data and other material into a file in which thesaid data structure is contained in one part of the file and the othermaterial is contained in another part of the file.

[0013] Preferably the file comprises a file header, a file bodycontaining the said other material and a file footer. Most preferablythe file is an MXF file and the data is Header Metadata thereof.

[0014] Material, especially video and audio, may be stored in variousdifferent types of store including tape recorders and file servers andtransferred between them. Thus by organising the combined data and othermaterial as a file the transfer is facilitated.

[0015] The said format may that of an SDI bitstream or that of an SerialData Transport Interface (SDTI) bitstream, the said other materialcomprising at least video material which is uncompressed in the case ofSDI and compressed in the case of SDTI. The compressed video material iscontained in a picture item of an SDTI bitstream. Both formats are basedon video frames.

[0016] Both formats may include audio frames, which can operate in audioand in non-audio mode. In an embodiment of the invention, the datastructure is included in audio frames operating in non-audio mode.

[0017] SDI has a Vertical Ancillary Data (VANC) space. In an embodimentof the invention, the said data structure is included in the VANC space.

[0018] In SDTI, the VANC is included in the picture item data space. Inan embodiment of the invention, the said data structure is included inthe VANC space.

[0019] SDTI also has a system item. In an embodiment of the invention,the said data structure is included in the system item.

[0020] In preferred embodiments the data structure is encoded in a groupof packets called a packet set. Each set includes an integer number ofwhole packets where the integer number includes one.. The packetsinclude integer numbers of whole KLV encoded items containing the dataof the structure where a value field V contains the data, a length fieldindicates the length of the value field and a key field indicates thetype of packet.

[0021] In SDI, one packet set preferably occupies one Vertical BlankingInterval (VBI) video line in the VANC space. The packet may benull-terminated to occupy one VBI line.

[0022] In SDI, each repetition preferably begins in a new frame, and ina new packet in a new packet set.

[0023] In SDTI, one packet set preferably occupies one uncompressedvideo line in the VANC space. The packet set may be null terminated tooccupy one whole line.

[0024] Alternatively, in SDI and in SDTI, one packet set preferablyoccupies one audio frame operating in non-audio mode. The packet may benull -terminated to occupy one whole audio frame.

[0025] Alternatively, in SDTI-CP, one packet set preferably occupies themetadata area of the system item data space.

[0026] A further aspect of the invention provides a computer programproduct containing program instructions which when run on a suitablesignal or data processor implement the method of said one aspect of theinvention.

[0027] Other aspects of the invention are specified in the claims towhich attention is invited.

[0028] For a better understanding of the present invention, referencewill now be made by way of example to the accompanying drawings inwhich:

[0029]FIG. 1 is a schematic diagram of the overall data structure of anMXF file;

[0030]FIG. 2 is a schematic diagram showing the data construct of headermetadata of FIG. 1;

[0031]FIGS. 3A to D are schematic diagrams showing the mapping of headermetadata over a packet stream;

[0032]FIG. 4 is a schematic block diagram of a signal processing andmaterial transfer system;

[0033]FIG. 5 is a schematic diagram of an SDI field;

[0034]FIG. 6 is a schematic diagram of an SDTI-CP frame;

[0035]FIG. 7 is a model of the data structure of SDTI-CP contentpackage;

[0036]FIG. 8 is a model of an element used in an SDTI-CP contentpackage;

[0037]FIG. 9 is a schematic diagram showing audio packets;

[0038] FIGS. 10 to 12 are schematic block diagrams of illustrativesystems for implementing the system of FIG. 4;

[0039]FIG. 13 illustrates a network showing the video and audio materialstreamed over SDI/SDTI interfaces together with file transfer over acomputer network interface; and

[0040]FIG. 14 illustrates an alternative system for implementing thesystem of FIG. 4.

MXF FILE

[0041] Referring to FIG. 1, there is shown the overall data structure ofa file. Such a file is referred to herein as an MXF file (MaterialeXchange Format). The purpose of the Material Exchange Format is toexchange programme material together with attached metadata informationabout the material body. The MXF file is intended for the transfer ofprogramme material and metadata between disc-based file servers forexample.

[0042] MXF files are defined by a sequence of Key, Length, Value (KLV)coded data packets.

[0043] Header Metadata is structured as follows:

[0044] Individual metadata items coded with KLV,

[0045] Logical groupings of metadata items coded as metadata sets codedby KLV where the Value is a collection of KLV coded metadata items, and

[0046] Logical groupings of metadata sets coded by KLV where the valueis a collection of KLV coded metadata sets;

[0047] where the top level is the Header Metadata at the outermostlevel. The file comprises a file header, a file body and a file footer.The body contains the “essence” that is, in this example, video and/oraudio essence data. The essence may alternatively be, or additionallyinclude, essence data. The following description refers only to videoand audio for convenience of description.

[0048] It will be appreciated that FIG. 1 is not drawn to scale. Thebody is much greater than the preamble and post amble. The body maycontain 99% or more of the total data content of the file.

The File Header

[0049] The file header contains a Preamble followed by Header Metadata.and optionally an index table.

[0050] The Pre-amble preferably starts with a fixed Run-in byte sequenceof e.g. 8 bytes. That is followed by Key, Length Value (KLV) encodedpreamble data pack which comprises:

[0051] an SMPTE Pack label of 12 bytes (the Key);

[0052] followed by one or more Length bytes, (4 in this example); whichis followed in this example by a null filled value field. The lengthbyte indicates the amount of data in the value field.

[0053] The SMPTE pack label defines the File as an MXF file

The File Footer

[0054] The MXF file is terminated by a File Footer. The footer containsan optional index table followed by a Post-amble.

[0055] The Post amble comprises a KLV encoded post-amble data pack. Thepost-amble data pack comprises a SMPTE pack label of 12 bytes, and oneor more length bytes (4 in this example). In this example there is novalue field and the length byte indicates a length of zero. In somecircumstances, a value may be in, or added to, the vale field but wouldbe ignored by an MXF decoder.

The Index Table

[0056] The index table provides a means of rapidly locating specificdata, e.g. video frame starts, in the file body.

[0057] The index table is an optional metadata set, which can be used tolocate individual frames of video essence and related audio and dataessence. Index files may be placed either immediately before the Body,immediately after the Body or optionally distributed throughout theBody.

[0058] An index table can be created ‘on the fly’ during file creationfrom a stream input and is notionally placed at the end of the file onrecording. In practice, its placement in a server file system may beanywhere for storage convenience. During transfer of a complete file,the Index table is placed in the MXF file header.

[0059] Index tables are not necessary for body container specificationswhich are defined with a constant number of bytes per frame, so theirinclusion in the MXF file is optional.

Header Metadata

[0060] The preamble comprises Header Metadata. The metadata may be anyinformation associated with the essence contained in the file body. Themetadata may be descriptive of the essence, be technical data relatingto the essence or any other information.

[0061] By way of example only, descriptive metadata may comprise datarelating to the production of video material such as Programme ID (PID),Title, Working Title, Genre ID, Synopsis, Director ID, Picturestamp,Keywords, Script, People, e.g. names and other details of performers andproduction crew.

[0062] By way of example technical metadata may comprise data such asdisplay aspect ratio, picture dimensions in pixels, picture rate, cameratype, lens identification, and any other technical data.

[0063] Metadata may also comprise data relating to edits in thematerial. It may comprise instructions defining simple editing and otherprocesses to be performed on the material.

[0064] Referring to FIG. 2, the Header Metadata of the preamblecomprises 16 bytes of Header Metadata Universal Label (UL), followed bya length byte followed by KLV encoded metadata sets (sets 1 to n) whichconstitute the data of the value field (V).

[0065] The UL defines the data value (V) following the UL as MXF HeaderMetadata.

[0066] Each KLV encoded metadata set n comprises a set UL of 16 bytes,which uniquely identifies that set, one or more length bytes and a setof KLV coded metadata items constituting the data in the value field Vof the set. The length byte indicates the length of the value field. TheUL defines the complete list of metadata items present in the set n.

[0067] Each item is KLV encoded, comprising a 16 byte item UL, one ormore length bytes and the data in the value field V. The UL defines thetype of content in the value field.

[0068] It will be appreciated that a set n may itself contain aplurality of KLV encoded sets of data. An item may contain one or moresets of KLV encoded data.

The File Body

[0069] An example of a file body will be described below. The example isan SDTI-CP content package containing MPEG encoded video. Othercontainers may be used.

[0070] The contents of the file body depend on the video, and/or audioand/or data essence contained in it and the manner in which it isencoded. For example, video may be compressed or uncompressed. Severaldifferent forms of compression are possible.

[0071] Each essence frame is KLV encoded in the file body. In the caseof an SDTI-CP content package, which contains different essence types,each type is separately KLV encoded.

[0072] Each container type has a unique and registered Universal LabelUL as a Key in the KLV coding.

[0073] Each essence type within a container may have a unique key.

[0074] The amount of data in the file body is unlimited and bound onlyby the file header and file footer. The data in the file body could befor example many Gigabytes.

MXF Header Metadata Repetition

[0075] The Header Metadata may be repetitively distributed through thefile body. The Header Metadata in the file body is additional to theHeader Metadata in the preamble. This has the advantages that:

[0076] if a file is interrupted during a transfer recovery of metadatais possible; and

[0077] an MXF file allows random access to data within the file body.The repetitive metadata allows easier and quicker access to metadatarelating to randomly accessed data because it avoids the need to scrollto the beginning or end of the file.

[0078] Repetition of Header metadata in the file body is optional buthas no connection with the repetition of metadata in accordance withembodiments of this invention.

[0079] The foregoing description sets out some of the basic features ofMXF files. There are other features but they are not relevant to thepresent invention.

System Overview

[0080] Referring to FIG. 4 a signal processing and material transfersystem comprises a source 10 of source code, an optional encoder 12, aninterface which formats the source code or the encoded source code intoa container and an interface 18 which encapsulates the container intothe body of an MXF file. The MXF file is transferred to an interface 20which decapsulates the file; i.e. retrieves the container from the body.The source code or the encoded source code is retrieved from thecontainer in an interface 22. If encoded the source code is decoded in adecoder 26. The source code may be utilised in a utiliser 28 which maybe for example a display device or any other processor which operates onor requires source code.

[0081] The transfer from the interface 18 to the interface 20 may be bystorage in a disc such as a computer data disc or transfer by acommunications network using Internet Protocol Packets for example.Other means of transfer may be used including other networks for exampleEthernet and Fibre Channel.

[0082] The encoder 14 may be a compression encoder such as an MPEG2encoder. Other forms of compression may be used. The decoder 26corresponds to the encoder.

[0083] The interface 20 is an MXF decoder which is able to decode atleast the following of an MXF file:

[0084] the KLV container structure of all parts of the file (includingthe data structure of any kind of Body);

[0085] the Header, including the Header Metadata structure; and

[0086] the Footer.

Stream Interface for Uncompressed Material.

[0087] An example of a stream interface for uncompressed digital videoand audio material is the Serial Digital Interface (or Interconnect)(SDI) defined in SMPTE 259M. SDI is well known in the art and so willnot be described in detail herein. FIG. 5 is a schematic model of videoand audio mapped onto the SDI structure. SDI uses interlaced fields InFIG. 5, SAV denotes Start Active Video, EAV denoted End Active Video, Hdenotes line scan direction and F denotes vertical scan direction.

[0088] The SDI transport comprises a video frame in which data iscarried in the lines of the frame. A field has essentially the samestructure. The frame has a Vertical Blanking Interval (VBI) a HorizontalBlanking Interval and an active video space. In SDI, the VBI can be usedfor the carriage of Vertical Ancillary Data (VANC), and the Horizontalblanking interval can be used for the carriage of Horizontal Ancillarydata (HANC). The active video space is the space for the main data, e.g.digital video. AES/EBU digital audio channels may be contained in theHANC as defined by SMPTE 272M. Such audio channels comprise audioframes, (which are explained in more detail below).

[0089] In accordance with illustrative examples of the invention, theVANC contains Header Metadata as described above.

[0090] In accordance with another embodiment Header Metadata may bemapped into audio frames of the audio channels. Each audio channel cancarry either audio or non-audio data where the non-audio data can be anydata such as metadata. Whether data in an audio frame is audio ornon-audio data is indicated by a flag in known manner.

Stream Interface for Compressed Material.

[0091] An example of a stream interface for compressed data such asMPEG2 is SDTI CP which is described in SMTPE 326M. FIG. 6 is a schematicdiagram of an SDTI-CP frame having two fields. An SDTI-CP field does notaccommodate vertical ancillary data VANC. The active video spacecontains lines allocated to “Items” System Item, Picture Item, AudioItem and Auxiliary Item. As shown in FIG. 7, the items contain one ormore elements. Elements are shown in FIG. 7 in relation to the pictureitem as an example. An item comprises one or more elements. An elementcomprises one KLV encoded data block as shown in FIG. 8. Compressedvideo is contained in a picture element within the picture item. An SDTIdata stream may be derived by mapping in known manner the data containedin an SDI data stream into an SDTI data stream, together withcompression of the video.

[0092] An MPEG2 Elementary Stream (ES) may embed Vertical Ancillary Datawithin the elementary stream according to the SMPTE standard SMPTE 328M.If the SDTI CP stream is derived from SDI and VANC data exists, the VANCdata is mapped into the MPEG2 ES Ancillary Data space. In accordancewith embodiments of the invention, the VANC data is Header Metadata. TheAncillary Data space uses one or more uncompressed video lines. The useof uncompressed video lines for ancillary data reduces the data space(bandwidth ) available for video.

[0093] An SDTI-CP audio item contains one or more audio elements whichmay contain 1 to 8 audio channels in each element. Each audio channelwithin an element can carry either audio or non-audio data where thenon-audio data can be any data such as metadata. Whether data in anaudio frame is audio or non-audio data is indicated by a flag in knownmanner. Header metadata may be mapped into audio frames in the audioitem in accordance with an embodiment of the invention.

Mapping Header Metadata Over a Packet Stream

[0094] In accordance with embodiments of the invention, Header Metadatais organised as shown in FIG. 3.

[0095] Referring to FIG. 3A, the overall data structure of HeaderMetadata is shown as a single entity, and is exactly the same as shownin FIG. 2. The complete Header Metadata data structure is KLV encoded asshown in and described with reference to FIG. 2. It comprises theUniversal Label (UL) of 16 bytes followed by one or more length bytesfollowed by n sets of metadata in the value field.

[0096] Referring to FIG. 3B, the complete data structure of FIG. 3A isdistributed into p Packet Sets

[0097] Referring to FIG. 3C, each Packet Set comprises m packets. Asshown in FIG. 3D each packet is KLV encoded. Referring to FIG. 3D, apacket comprises

[0098] a packet start sequence,

[0099] a data type byte,

[0100] a length byte,

[0101] a 1 byte channel ID,

[0102] a packet count of two bytes,

[0103] a set of complete metadata KLV blocks and

[0104] a CRC code.

[0105] The channel ID plus the packet count plus the KLV blocks containa maximum of 255 bytes in this example.

[0106] The channel ID provides a means of interleaving many differentchannels of metadata relating to different channels of essence. Thechannel ID identifies the channel to which the metadata belongs.

[0107] Ideally, the value field of a packet contains a set of completeKLV encoded metadata items as shown in FIG. 2. However it is possiblethat an item has more than 252 bytes. In that case, the value field ofthe metadata item may be contained in more than one consecutive packetof a sequence eof packets. The first packet of the sequence has a key,e.g. of 16 bytes, to allow the packets of the sequence to be identifiedand to maintain the continuity of the data of the metadata item.

[0108] The first packet in a frame, if it is part of a multi packetsequence, also has such a key.

[0109] The packet count identifies the packet number within the definedchannel number. Typically, this count uses 2 bytes which allows asequence of up to 65536 packets. Packet count ‘0’ is always the firstpacket in the message. Thus for example the packet count begins withpacket 0 in packet set p=1 and continues incrementing throughout the ppacket sets.

Mapping of Packets in Accordance with Embodiments of the Invention

[0110] The packets of Header Metadata are mapped, and embedded in an SDIor SDTI data stream, on a repetitive basis, as follows:

[0111] a) for uncompressed video over SDI, it is mapped into one or moreVBI lines as VANC data;

[0112] b) for compressed bitstreams in SDTI, it is mapped into one ormore compressed video frames of payload data space, being mapped intothe ancillary data space such as may be provided by extensions to theMPEG2 ES syntax (as provided by the SMPTE standard SMPTE 328M); or

[0113] c) alternatively to a) and b), it is mapped into one or moreaudio frames of one or more audio channels, e.g. AES 3 channelsoperating in non-audio mode. Such channels exist in SDI, and in SDTI-CP.

[0114] d) The Header Metadata is padded to occupy an integer number offrames, so that when the Header Metadata is repeated it always starts inthe same place on a new frame. By starting each complete data structureof Header Metadata on a new frame, break-up in editing operations isreduced or minimised.

[0115] e) The Header Metadata is packetised with a packet structurewhich includes at least the packet channel identification (the channelID) for multiplexing with other packetised metadata, and the packetsequence count (so detection of the first packet is easy)

[0116] f) each repetition of a complete Header Metadata data structurestarts in a new packet, preferably packet 0, for ease of data parsing

[0117] g) Referring to FIG. 9, when mapping Header Metadata into AES3non-audio frames, the Metadata is mapped into a window spaced from thebeginning and end of the audio frame by guard bands to increasereliability in the presence of timing errors or edits. The guard bandsare null-filled.

[0118] An audio frame is the amount of audio data which occurs in thetime interval of a video frame. For example, if analogue audio is sampleat 48 KHz, and the video frame rate is 25 Hz, then an audio frameconsists of 48000/25 bytes=1920 bytes.

[0119] Referring to FIG. 3B:

[0120] In SDI, the packet sets 1 to p are assigned to respective VBIlines in SDI and most preferably only two lines of VBI are used per SDIframe, (i.e. one line per field) although more than two lines per framecould be used;

[0121] b) In SDTI, the packet sets 1 to p are allocated to the ancillarydata space within an MPEG2 ES data stream;

[0122] c) Alternatively, in SDI and in SDTI the packet sets 1 to p areallocated to respective audio frames. Preferably one audio framecontains only one packet set.

[0123] Each packet set preferably occupies a whole SDI VBI line or audioframe with one packet set per line or per audio frame. Any spare dataspace on the line or in the audio frame is null filled. One line or oneaudio frame typically contains about 1400 bytes in examples of theinvention, that is about m=5 packets using V-ANC as shown in FIG. 3C.Because one complete Header Metadata data structure is likely to be muchgreater than the data space available in one frame, it is spread overmany packet sets 1 to p. For that purpose, the packet count is usedsequentially to identify all the packets over which it is spread andwhich contain one complete Header Metadata data structure. Because anyspare space in a packet set in any frame is null-filled then thecomplete Header Metadata data structure occupies an integer number offrames. Once a complete Header Metadata data structure has beendistributed over one group of p packet sets it is repeated in thesucceeding group of p packet sets.

[0124] The repeat of the complete Header Metadata data structure beginsin a new frame with packet 0 in packet set 1.

[0125] Several different complete Header Metadata data structures may beinterleaved in respective channels identified by the channel IDs.

[0126] In summary, a complete Header Metadata data structure isdistributed over an integer number of packet sets. Each packet set hasan integer number of packets. Preferably, one packet set occupies onlyone VBI line in SDI or one audio frame; any data space not used on theline or in the frame is null-filled. Each repeat of a complete HeaderMetadata data structure begins on a new video or audio frame in a newpacket of preferably preset number such as packet 0. This allows eachcomplete Header Metadata data structure to be easily identified and itsstart position is easily found because it is consistently aligned withthe video frames in SDI or with the audio frames in SDI and SDTI.

[0127] In SDTI where the Header Metadata is embedded in an MPEG2 ES datastream in an SDTI picture item, the packets are contained in Ancillarydata lines in accordance with SMPTE 328M.

Illustrative Implementations of the Invention

[0128] FIGS. 10 to 12 are schematic block diagrams of illustrativesystems for implementing the system of FIG. 4, with the repetition ofHeader Metadata in accordance with the invention. In FIGS. 10 to 12 likeblocks are denoted by like reference numerals. The followingdescriptions of FIGS. 10 and 12 ignore the audio channel because it isnot used in the embodiments of FIGS. 10 and 12 for containing HeaderMetadata.

[0129] In FIG. 10, Header Metadata is created in a metadata creator 30.The header metadata has the data structure shown in FIGS. 2 and thatmetadata structure is mapped into the packets shown in FIG. 3 Asdescribed above in the section “Mapping of Packets in accordance withembodiments of the invention”, the Header Metadata is inserted into theVANC of an SDI data structure using a suitable multiplexer 90 in an SDIinterface 32 and the Header Metadata is repeated, each repeat beginningin a new packet (packet m=0) at the beginning of a VBI line in a newframe, each complete Header Metadata data structure occupying a integernumber of frames. Preferably as described above one frame contains onlyone whole packet set p on one VBI line.

[0130] The SDI data structure contains uncompressed digital video in itsactive video data space. An MPEG encoder 34 compresses the digital videointo an MPEG2 ES elementary stream and maps the SDI VANC containing theHeader Metadata into the ancillary data space of the elementary stream.

[0131] An SDTI-CP interface maps the MPEG2 ES, containing the repeatedHeader Metadata, into the picture item of an SDTI-CP content package.There is no predetermined position or timing of the Header Metadata inthe picture item of the SDTI-CP content package.

[0132] A digital data store such as a digital video tape recorder ordigital disc recorder 38 which is designed to store SDTI-CP contentpackages records the SDTI-CP content package. Because the HeaderMetadata is in the MPEG2 ES contained in the picture item, the recorder38 is able to store the repeated metadata without violating itsformatting rules.

[0133] The video and the header Metadata may need to be transferred to acomputer network and/or computer file storage denoted schematically at46. For that purpose it is converted to an MXF file in this illustrativeembodiment. The SDTI-CP bitstream is reproduced by the recorder 38 andfed to a de-embedder 40. The de-embeddder 40 separates the HeaderMetadata from the compressed MPEG2 ES of the SDTI-CP content package andsupplies them to an MXF file creator 42. Assuming the SDTI CP bitstreamcontains only one Header Metadata structure and its repeats, thede-embeddder preferably supplies only one complete Header Metadata datastructure (and no repetitions of it) to the creator 42. The MXF creator42 maps the Header metadata into the file header of the MXF file and theMPEG2 ES stream into the file body of the MXF file as shown in FIG. 2.

[0134] The MXF file may be transferred to the network and/or computerfile storage denoted schematically at 46. The MXF file may betransferred from the network and/or storage 46 to a recorder 54, whichmay be identical to the recorder 38. The MXF file is fed to ademultiplexer 48, which separates the Header Metadata from the file bodyof the MXF file. The compressed MPEG2 ES stream of the file body and theHeader Metadata are fed to respective inputs of an encoder 50 whichrepetitively embeds the Header Metadata into the ancillary data space ofthe MPEG2 ES stream which is then embedded in the picture item of anSDTI-CP content package by an SDTI interface 52. The SDTI-CP bitstreamis recorded in the recorder 54. The SDTI-CP bitstream may be reproducedby the recorder 54 and fed to an SDTI decoder 56, which outputs theMPEG2 ES stream containing the repeated Header Metadata in its ancillarydata space. The video is decompressed by an MPEG2 decoder 58 and theHeader metadata is mapped into the VBI of an SDI stream and thedecompressed video is mapped into the active video space of the SDIstream. The decompressed video and the Header Metadata may be derivedfrom an SDI interface 60.

[0135] The embodiment of FIG. 11 uses an audio channel to contain headermetadata. Referring to FIG. 11, Header Metadata is created in a metadatacreator 30. The header metadata has the data structure shown in FIGS. 2and 3. The Header Metadata is inserted into audio frames as shown inFIG. 8 using a suitable multiplexer 92 in an audio interface 44 and theHeader Metadata is repeated, each repeat beginning in a new packet(packet m=0) at the beginning of a a new frame, each complete HeaderMetadata data structure occupying a integer number of frames. Preferablyas described above one frame contains only one whole packet set p whereeach packet set contains only one packet.

[0136] The SDI bitstream contains uncompressed digital video in itsactive video data space. An MPEG encoder 34 compresses the digital videointo an MPEG2 ES elementary stream.

[0137] An SDTI-CP interface 36 maps the MPEG2 ES, into the picture itemof an SDTI-CP content package. The audio containing the repeated HeaderMetadata is mapped into the audio item of the SDTI-CP content package.

[0138] The blocks 38 to 48 of the embodiment of FIG. 11 operate in thesame way as discussed with reference to FIG. 10.

[0139] The encoder 50 embeds the header metadata repetitively into audioframes and an SDTI-CP encoder 52 maps the audio frames to the audio itemof an SDTI-CP content package and maps the compressed video to thepicture item. The SDTI-CP bitstream is recorded in recorder 54reproduced and decoded in a decoder 56, which separates the audio fromthe MPEG2 ES stream. An audio decoder 62 separates and outputs theHeader Metadata and audio.

[0140] The embodiment of FIG. 12 operates in much the same way as thatof FIG. 10 except that the Header Metadata produced by creator 30 isembedded using a multiplexer 94 of an SDTI encoder 36 in the system item(shown in FIG. 6) of an SDTI-CP content package. Referring to FIG. 6,the Header UL of the Header Metadata follows immediately after the SAVin the system item. Blocks 38 to 54 operate as described with referenceto FIG. 10. The SDTI decoder 56 separates the Header Metadata from thesystem item.

[0141] Those skilled in the art will recognise that, at the prioritydate of this patent application, whilst SDTI with system items isallowed in the relevant SMPTE standards, many data recorders, asexemplified by 38 and 54, do not yet support the use of system items.

Illustrative Network

[0142]FIG. 13 illustrates a network which uses streaming format signalssuch as SDI and SDTI and MXF files. An SDI bitstream is supplied to anMPEG digital video tape recorder 100. The recorder 100 MPEG encodes thevideo (and audio) components of the SDI bitstream and records theencoded components. The recorder in this example outputs an SDTI-CP orSDTI-DV bitstream containing the encoded components for transfer to avideo file server 102 which records streaming format signals. The server102 has an interface which produces MXF files and delivers MXF files toa computer network 106 having file servers 104, a router 108, a controlcomputer 110 and a Tape archive 112. The MXF file allows exchange ofmaterial between the file servers 104, the archive 112 and the videofile server 102.

[0143] Header metadata is mapped into the SDI and SDTI bitsreams asdescribed above. The MXF files are produced by the server 102 asdescribed above.

Modifications

[0144] Embodiments of the invention have been described above withreference to MPEG2 compression systems. Any other compression systemsmay be used.

[0145] Embodiments of the invention have been described above withreference to MXF files. Other types of file may be used provided theHeader Metadata repeated as described above can be mapped into the file.

[0146] Embodiments of the invention have been described above withreference to SDI and SDTI. Other formats can be used provided the HeaderMetadata can be packetised, repeated and mapped into video or audioframes as described above.

[0147] FIGS. 10 to 12 show mapping of SDI into SDTI followed by mappingof SDTI into an MXF file. In alternative embodiments, SDI is mappeddirectly into an MXF file, the file body containing uncompressed video.The Header Metadata is contained in audio frames or in the VBI lines inthe file body. Thus referring to FIG. 14 Header Metadata is created by acreator 30. Audio is encoded by an encoder 44. An SDI encoder 32 insertsuncompressed video into the active data space. The header Metadata isinserted into either audio frames operating in non-audio mode or intothe VBI as described above. The metadata is repetitively distributedover the SDI video frames in the VBI or in the audio frames as describedabove. A recorder 381 records the SDI bitstream without compression ofthe video. The recorder may be a disc recorder or a tape recorder TheSDI bitstream is reproduced from the recorder and a data de-embedder 40separates the Header Metadata from the video and audio. An MXF filecreator 42 maps the Header Metadata into the file header and the videoand audio into the file body as shown in FIG. 1. The MXF file may betransferred to the network and/or computer file storage denotedschematically at 46. The MXF file may be transferred from the networkand/or storage 46 to a recorder 541, which may be identical to therecorder 381. For that purpose, the MXF file is fed from thenetwork/storage 46 to an SDI encoder which maps the MXF file into an SDIbitstream with repetition of the Header Metadata as described above. Therecorder 541 records the SDI bitstream which may be reproduced therefromand an SDI decoder 60 separates the Header Metadata, the video and theaudio.

[0148] The invention may be implemented on a digital signal or dataprocessing system which is programmable. Thus the invention may be acomputer program product containing instructions which when run on thesignal or data processing system implement the invention.

1. A method of combining digital data with other digital materialcomprising the steps of: structuring the said digital data into apredetermined data structure; creating a digital bitstream having apredetermined repetitive format compatible with a data recorder eachrepetition of the format including at least one data space for the saidother material and a data space for other data; and repetitivelyincluding the data structure over a plurality of repetitions of theformat, the said data structure being included in the said other dataspace or in part of the data space of the said other material.
 2. Amethod according to claim 1, wherein the said digital data is metadataassociated with the other material.
 3. A method according to claim 1 or2, wherein the said other material comprises video material.
 4. A methodaccording to claim 3, wherein the said at least one data space for theother material includes a video data space.
 5. A method according toclaim 1, 2 or 3, wherein the said other material comprises audiomaterial.
 6. A method according to claim 5, wherein the said at leastone data space for the other material includes an audio data space.
 7. Amethod according to claim 6, wherein the said digital data is includedin the audio data space.
 8. A method according to any one of claims 1 to8, wherein the said digital data is included in the said other dataspace.
 9. A method according to any preceding claim, wherein the saidother data space is an ancillary data space.
 10. A method according toany preceding claim, wherein the said data structure comprises a valuefield containing the said data, a key field and a length fieldindicating the amount of data in the value field.
 11. A method accordingto any preceding claim wherein the said format is repeated in frames,and each repetition of the said digital data structure begins on a framecontaining no data of a previous occurrence of the said data structure.12. A method according to claim 11, wherein each occurrence of the saiddata structures is distributed over an integer number of frames.
 13. Amethod according to claim 11 or 12, wherein the said data structurecomprises packets of data, and each repetition thereof starts in apacket containing no data of a previous occurrence of the datastructure.
 14. A method according to claim 12, wherein the packets areordinally numbered and each repetition of the data structure begins in apacket having a predetermined number.
 15. A method according to claim 13or 14, wherein each frame contains a set of packets of the datastructure, each set consisting of an integer number of complete packets.16. A method according to claim 11, 12, 13, 14 or 15, wherein the saidrepetitive format is that of a Serial Digital Interface (SDI) bitstream.17. A method according to claim 16, wherein the said data structure isrepetitively included in audio frames operating in non-audio mode.
 18. Amethod according to claim 17, when dependent on claim 12 or 13, whereineach set of packets is contained in a window within an audio frame, thewindow being spaced from the boundaries of the frame by guard bands. 19.A method according to claim 17, wherein the said data structure isincluded in a Vertical Ancillary data space (VANC) of the SDI bitstream.20. A method according to any one of claims 16 to 19, comprising thefurther step of creating an Serial Data Transport Interface (SDTI)bitstream from the content of the SDI bitstream.
 21. A method accordingto claim 10 or 11, wherein the audio frames are contained in an SDTIdata structure.
 22. A method according to claim 11, 12, 13, 14 or 15,wherein the said other material comprises at least video material, andthe said repetitive format is that of an SDTI bitstream having at leastan audio item and a picture item.
 23. A method according to claim 21,wherein the said data structure is repetitively included in audio framesoperating in non-audio mode in the said audio item.
 24. A methodaccording to claim 22 when dependent on claim 12 or 13, wherein each setof packets is contained in a window within an audio frame, the windowbeing spaced from the boundaries of the frame by guard bands.
 25. Amethod according to claim 21, wherein the said data structure isincluded in a Vertical Ancillary data space (VANC) within the pictureitem of the SDTI bitstream.
 26. A method according to claim 21 whendependent on claim 12 or 13, wherein one set of packets is contained inone line of the Vertical Ancillary data space.
 27. A method according toclaim 21, wherein the SDTI bitstream comprises a system item and thesaid data structure is included in the system item.
 28. A methodaccording to any preceding claim, wherein a plurality of different datastructures having respective identifiers are repetitively distributed inthe said format.
 29. A method according to any preceding claimcomprising the step of mapping the combined data and other material fromthe said repetitive format into a file in which the said data structureis contained in one part of the file and the other material is containedin another part of the file.
 30. A method according to claim 29, whereinthe file comprises a file header, a file body containing the said othermaterial and a file footer.
 31. A method according to claim 29 or 30,wherein the file is an MXF file and the data is Header Metadata thereof.32. A method according to claim 29, 30 or 31, comprising the furtherstep of mapping the data structure and the other material from the fileinto digital bitstream having a predetermined repetitive formatcompatible with a data recorder each repetition of the format includingat least one data space for the said other material and a data space forother data; and repetitively including the data structure over aplurality of repetitions of the format, the said data structure beingincluded in the said other data space or in part of the data space ofthe said other material.
 33. A method comprising the steps of: receivinga digital bitstream including digital data in a predetermined datastructure and other digital material, the bitstream having apredetermined repetitive format compatible with a data recorder eachrepetition of the format including at least one data space for the saidother material and a data space for other data and repetitivelyincluding the data structure over a plurality of repetitions of theformat, the said data structure being included in the said other dataspace or in part of the data space of the said other material; andseparating the said data structure from the other material.
 34. A methodaccording to claim 33 comprising the further steps of deriving the saidsignal from a file, into which the said data structure and othermaterial is mapped and wherein the said data structure is contained inone part of the file and the other material is contained in another partof the file, by inverse mapping the said data structure and the othermaterial from the file into the said signal.
 35. A method according toany preceding claim and substantially as hereinbefore described withreference to FIGS. 1 to 13 of the accompanying drawings.
 36. Signalprocessing apparatus arranged to carry out the method of any precedingclaim.
 37. A computer program product arranged to carry out the methodof any one of claims 1 to 35 when run on a signal processor.
 38. Adigital bitstream including digital data in a predetermined datastructure and other digital material, the bitstream having apredetermined repetitive format compatible with a data recorder eachrepetition of the format including at least one data space for the saidother material and a data space for other data; and repetitivelyincluding the data structure over a plurality of repetitions of theformat, the said data structure being included in the said other dataspace or in part of the data space of the said other material.
 39. Abitstream according to claim 38, and produced by the method of any oneof claims 1 to
 35. 40. A bitstream according to claim 39 andsubstantially as hereinbefore described with reference the accompanyingdrawings.